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(57) Abstract: A method and system for improving the registration process in a communication system, preferably an aj] IP com- 
munication system, wherein a set of Location Registration (LR) nodes are designed to handle mobile registration locally. When 
the mobile node registers with the home network from a foreign network, a Location Registration chain is established through these 
nodes. The information needed for the mobile node to access the network is distributed to these nodes from the home network. When 
the mobile node roams into a different visiting network or returns to its home network, the nearby location registration nodes then 
process the mobile registration and update the location chain accordingly. 
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MULTIPLE TREE HIERARCHICAL COMMUNICATION SYSTEM AND 

METHOD 

Field of the Invention 

The present invention is related in general to communication systems, 
and, more particularly, to an improved method and system for improving 
the registration process in an all IP communication system. 

Background of the Invention 

A universal personal communication system is a system enabling 
anyone to communicate with anyone else anywhere in the world. One of the 
problems of such a system would be locating millions of moving customers 
in an efficient manner. Existing techniques for locating moving customers in 
the system are paging and registration using a central database. Considering 
the large number of customers in a global system, the first technique, if 
applied without knowledge of the location of the customers, is impractical. 
The registration technique, which records all the movements of customers in 
a central database, is also impractical. 

Global roaming is one of the design objectives for the next or third 
generation (3G) cellular networks. To efficiently support real-time 
applications for mobile users in these networks, signaling and payload traffic 
delays must be minimal. It has been identified that one of the sources 
causing long delays is triangle routing. That is, for example, in the 
registration process the registration requests have to be transmitted from a 
foreign agent in the visited network all the way to the home network every 
time the mobile node initiates a call or when the mobile node roams into a 
different visiting network. In addition, in the call set up process, triangle 
routing has been identified as a source causing long delays. 

In a Mobile IP network as specified in RFC2002, a home agent serves 
as both a centralized location registry and as a tunneling endpoint, such that 
all packets destined for a mobile node must be routed to its home agent and 
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then encapsulated and forwarded to the corresponding foreign agent. This 
scenario is commonly called triangle routing or tromboning, which does not 
make efficient use of network resources and is one of the major obstacles for 
IP networks to support real time applications. 

The Regional Tunnel Management introduced a hierarchical foreign 
agent architecture to the IP network to remove triangle routing for the 
registration signaling. However, there are several issues when adopting 
Regional Tunnel Management to the 3G cellular networks. They include: 
inhomogeneous system architectures in home and foreign domains; triangle 
routing in call connection; inability to support personal (compared with 
device) mobility; undefined de-registration process for mobility 
management; and requiring heavy involvement of the mobile node in Hie 
registration process. 

The proposed Universal Mobile IP (UMCP) technology is designed for 
next generation (3G) cellular networks. It is intended to offer integrated 
mobility services, with global coverage, to multiple heterogeneous Radio 
Access Networks for real-time and non-real time applications. The proposed 
technology adds features to, and is backward compatible with, the Mobile IP 
standard specified in RFC2002, which is a special case of UMTP. The 
Regional Tunnel Management is also a special case of UMCP. 

Consequently, a need exists for a method and system for reducing the 
time required for call setup and payload routing. The present invention 
proposes to eliminate triangle routing in both signaling and payload traffic 
through a distributed hierarchical architecture in both the mobile's visiting 
domain and home domain. 
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Brief Description of the Drawings 

The novel features believed characteristic of the invention are set forth 
in the appended claims. The invention itself, however, as well as a preferred 
mode of use, further objects, and advantages thereof, will best be understood 
by reference to the following detailed description of an illustrative 
embodiment when read in conjunction with the accompanjring drawings, 
wherein: 

FIG. 1 illustrates a simplified 3G wireless network architecture in 
accordance with the method and system of the present invention; 

FIG. 2 illustrates a communication system in accordance with the 
method and system of the present invention showing the hierarchical system 
architecture with four layers of Location Registers; 

FIG. 3 illustrates a Location Register table to store mobile node 
location information; 

FIG. 4 illustrates an example of the location chain in the hierarchical 
architecture in accordance with the method and system of the present 
invention; 

FIG. 5 illustrates a functional flow diagram depicting the process of a 
Location Register of layer > 1 receiving a registration request; 

FIGS. 6 & 7 illustrate functional flow diagrams depicting the process 
of a Location Register generating a registration reply; 

FIG. 8 illustrates a functional flow diagram depicting the process of a 
Location Register of layer > 1 receiving a registration reply; 

FIG. 9 illustrates a functional flow diagram depicting the process of 
mobile nodes generating a registration request; 
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FIG. 10 illustrates a functional flow diagram depicting the process of 
mobile nodes receiving a registration reply; 

FIG. 11 illustrates a functional flow diagram depicting the process of 
mobile nodes generating a Lifetime update request; 

FIG. 12 illustrates a functional flow diagram depicting the process of 
mobile nodes receiving a Lifetime update reply; 

FIG. 13 illustrates a functional flow diagram depicting the process of 
Location Register (1) receiving a registration request; 

FIG. 14 illustrates a functional flow diagram depicting the process of a 
Location Register with a layer = 1 receiving a registration reply; 

FIG. 15 illustrates a functional flow diagram depicting the process of a 
Location Register with a layer = 1 receiving a binding update; 

FIG. 16 illustrates a functional flow diagram depicting the process of a 
Location Register with a layer = 1 receiving a de-registration; 

FIG. 17 illustrates a functional flow diagram depicting the process of a 
Location Register with a layer = 1 receiving a Lifetime update request; 

FIG. 18 illustrates a functional flow diagram depicting the process of a 
Location Register with a layer = 1 receiving a Lifetime update reply; 

FIG. 19 illustrates a functional flow diagram depicting the process of a 
Location Register of layer > 1 receiving a de-registration message; 

FIG. 20 illustrates a functional flow diagram depicting the process of a 
Location Register of layer > 1 receiving a binding update; and 

FIG. 21 illustrates a functional flow diagram depicting the process of a 
Location Register of layer > 1 receiving a Lifetime update request. 
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Detailed Description of the Invention 

Referring to the Figures and throughout the specification, acronyms 
are used for convenience. The following is a list of the acronyms used. 



Bluetooth 



BBit 
BRAN 
BTS 
CN 

Current ID 

DECT 

DNS 

FBit 

FA 

FD 



HBit 
HA 

Home ID: 
Home Network 



HD 



Bluetooth is the codename for a technology specification 
for small form factor, low-cost, short-range radio 
links between mobile PCs, mobile phones and other 
portable devices. The Bluetooth Special Interest Group is 
an industry group consisting of leaders in the 
telecommunications and computing industries that are 
driving development of the technology and bringing it 
to market. 
Busy 

Broadband Radio Access Network 
Base Transceiver Station 
Core IP-based Network 

The ID (NAI) of an LR to which the mobile node has 

successfully registered 

Digital European Cordless Telephone 

Domain Name Server 

Foreign Agent 

Foreign Agent 

Foreign Domain. The coverage area that is outside the 
Home Domain from which the mobile node subscribes 
network services 
Home Agent 
Home Agent 

The ID (NAI) of the mobile node assigned by its home 
LR from which the MN subscribes network services. 
The coverage area of the home LR from which an MN 
subscribes network services 

Home Domain. The entire area covered by the top layer 
LR that includes the home sub-tree where the mobile 
node subscribes network services 
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ER Intelligent Routing 

IrDA Infrared Data Association 

Location Chain A sequence of location pointers at LRs forming a routing 

path between MN's current LR and its home LR 

Location Pointer IP address of an LR to which outbound packets are 

forwarded for a mobile user 

LR Location Registration or Location Register, a network 

entity in the IP network to handle mobility management 

MIN Mobile Node Identification Number 

MN Mobile Node 

NAI Network Access Identifier 

NE Network Entity including LR, RNN. 

New ID The ID (NAI) of the LR which a mobile user newly 

discovered and to which Universal Registration Request 
messages are sent 

PDSN Packet Data Service Node 

RAN Radio Access Network 

RNN Radio Network Node for voice / data applications 

RNS Radio Network Subsystem 

RT Regional Tunnel 

UMIP Universal Mobile IP 

VHE Virtual Home Environment 



AA: 

Authen: 

Cch(i): 

Ccn*(i): 

Chn*(i): 

branch 

Cnc(i): 

Cnh(i): 



Mobile IP Agent Advertisement message 
Authentication 

True when the MN's current and home addresses (NAI) 
are the same at layer i and above 

True when the layer i processing node is on the current 
branch 

True when the layer i processing node is on the home 

True when the MN's new and current addresses (NAI) 
are the same at layer i and above 

True when the MN's new and home addresses (NAI) are 
the same at layer i and above 
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Cnn*(i): True when the layer i processing node is on the new 

branch 

CRN: Current root node, the root node of the tree which MN is 

registered 
DR: De-registration 

FL: Forwarding link address carried in messages 

FRN: Foreign root node, the root node of the tree which is not 

MN's home 

FWD; Forwarding, indicating the Status of MN entry 

HB: Home branch, the branch connecting MN home LR all 

the way to HRN 

HRN: Home root node, the root node of the tree which MN 

subscribes services 
I: The highest layer of LR nodes in UMIP hierarchy 

i: Indicating the layer of the LR node, [1, 1] 

LRh(i): Layer i Location Register on the home branch 

LRn(i): Layer i Location Register on the new branch 

LT: Lifetime 
LTR: Lifetime Update Request 

n*: The node processing the message 

NACK: Negative ACKnowledgment 

NRN: New root node 

PTR: Pointer indicating the next LR in the chain toward MN 

Rch: The index identifies the layer where the current branch 

and home branch split, [0, 1] 
Rnc: The index identifies the layer where the new branch and 

current branch split, [0, 1] 
Rnh: The index identifies the layer where the new branch and 

home branch split, [0, 1] 
RN: Root node 

RR: Registration Request 

RR FL: FL carried in Registration Request message 

TA: Target address for message to be sent 



A simplified 3G wireless network architecture is shown in FIG. 1. As 
shown, there are two separate network segments in the architecture. The first 
segment is the Radio Access Network (RAN) that includes the Radio 
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Network Node (RNN), which is associated with a coverage area such as a 
zone, paging area or routing area. The second segment of the system is the 
Core Network (CN) which offers an integrated mobility solution to all the 
underlying heterogeneous RANs, among other functions. 

FIG. 2 illustrates a UMTP system architecture with four layers of 
Location Registers (LRs). The RNN is the lowest layer LR (i.e., LI LR) in the 
hierarchy. In a preferred embodiment, either a unique NAI or an IP address 
identifies an LR in the hierarchy. Different wireless systems may have their 
own network entities that are equivalent to the RNN. For example, the Radio 
Network Subsystem (RNS) is an equivalent entity in a GPRS network. The 
RNN is responsible for both voice and /or data applications. Each RNN is 
identified by a single location ID and is shared by multiple Base Transceiver 
Stations (BTSs) under its control. It is assumed that the RNN has a link layer 
connection (e.g., common control channels or the equivalent) with the 
Mobile Node (MN). 

The RAN is responsible for all the radio access and micro mobility 
management (if any) issues. The core network (CN) may support multiple 
radio access technologies such as WCDMA, CDMA2000, GSM, IS-95, DECT, 
BRAN (Broadband Radio Access Network), BLUETOOTH, IrDA, and other 
future technologies. For example, a CDMA user may want to talk directly to 
a GSM cellular user by simply dialing the called party ID. The proposed 
solution is able to locate the called party with the help of the distributed LR 
database and make an appropriate connection to the called party. As a by- 
product of UMIP, the Network-Network Interface (NNI) is pushed down to 
the RAN-CN interface that should maximize CN reuse and system 
integration for mobility management. The RAN-CN interface for 
management functions such as mobility management is marked as "M- 
interface" in FIG. 2. No matter what technology is implemented for the 
RAN, in the preferred embodiment, the RAN-CN interface must be IP based. 

Mobility management is implemented in the LRs (Location Registers). 
In addition to serving as a foreign agent and replying to registration requests 
for the home agent, the LRs maintain and update the mobility database. The 
LRs are organized in a multiple-layered architecture (The maximum layer i 
equals 4 in FIG. 2). The layer index is assigned in an increasing order from 
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bottom to top of the architecture. The number of layers in different sub-trees 
(domains) may not necessarily be identical. Each LR may have zero or 
multiple child LRs in the next lower layer. Each LR may have zero (called 
root LR) or one immediate parent LR. All the root LRs are assumed to be able 
to communicate with each other to form a location chain across multiple 
domains. Each LR is associated with a logical coverage area. The total 
coverage area of a lower layer LR must be a proper sub-set of that of its 
parent LR. In other words, the logical boundary of a higher layer LR must 
not cross any boundaries of its offspring LRs. 

The behavior of each LR may be different depending on the layer at 
which it is located. Only those LRs that have a wireless interface to a MN 
need to advertise their presence to MNs. It should be noted that an LR at a 
given layer can have subtending child LRs and an interface to a RAN. The 
root LR in a hierarchy can interface with the root nodes in other hierarchies. 

In addition to their IP addresses, all the functional entities (i.e. LRs, 
RNNs and MNs), are identified by their globally unique identifiers. In the 
preferred embodiment, NAI (Network Access Identifier) is used as the 
globally unique identifier. However, those skilled in the art will appreciate 
that other globally unique identifiers may be used without departing from 
the spirit and scope of the present invention. 

In the preferred embodiment, in order to have an efficient system 
solution, the assignment of NAIs follows the following rules: The mobile 
user is identified by his/her NAI. This offers an opportunity to support 
Personal Mobility in UMEP. The NAIs, rather than the IP addresses, of the 
bottom layer LRs are used as the Current, New, or Home location identifiers 
for the mobile nodes. The NAIs of the LRs should be assigned in a way that 
by comparing the mobile user's Current, New, or Home identifiers, the LR at 
any layer should be able to make routing decisions. 

Complete specification of the NAI assignment is outside the scope of 
this invention. However, one method of implementation is to assign a 
shorter NAI for a higher layer entity, and have the assigned NAI be a postfix 
of the NAI assigned to its child entity of a lower layer. For example, a Layer 
1 LR may have an NAI as " 123.Ajlington Heights.Chicago.IL US@abc ." A 
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Layer 2 LR may have an NAI as " Arlington Heighte.Chicago.IL US@abc ." 
A Layer 3 LR may have an NAI as " Chicago.IL US@abc ." A Layer 4 LR may 
have an NAI as "TL US@abc ." Finally, a mobile user registered with the 
Layer 1 LR may have an NAI as 

5 "4567 123,Arlington _Heights.Chicago.IL_US@abc / / It should be noted that 
the NAI is defined in such a flexible way that an all-numeric numbering 
(such as a telephone number) is a valid NAI. In addition, all existing IP, 
IMSI, and MIN addressing schemes could also be treated as a valid NAI. 
Furthermore, the NAIs of all the network entities, including LRs and mobile 

10 users, may be re-assignable for scalability considerations. The proposed 
solution also works for mobile users with a permanently assigned NAI. 
However, a re-assignable NAI is preferred. The efficiency in assigning NAI 
is an issue of implementation. UMEP supports both pre-assigned and re- 
assigned NAIs. 

15 

With reference to FIG. 3, in each of the LRs, there is an LR table to 
store MN location information and for routing. In the preferred 
embodiment, and under the following conditions, there is an entry created 
and maintained in the LR table for a mobile user: the mobile user is outside 
20 its registered home network and 

the LR is on the location chain. The location chain begins at the mobile user's 
bottom layer LR in its Home Domain and ends at the bottom layer LR in its 
visited Network. In the preferred embodiment, when no entry is found in 
the LR table, the mobile node is assumed to be in its home network. 

25 

As seen in FIG. 3, in the preferred embodiment there are at least five 
entities in the LR table. They are keyed index, pointer, status of pointer, 
Lifetime, and replay protection, each of which, is described as foDows. The 
first column of the LR table is the keyed index, which is the mobile user's 

30 home NAI. It is used by the LR to look up mobile information to process 
registration and location updates and the call connection. There must be a 
mechanism in the proposed solution to map from a mobile user's 
identification (NAI) to a routable IP address. The mapping function is 
performed at LR. The second column is a location pointer of the mobile user. 

35 A location pointer for a mobile user is an IP address of an LR to which the LR 
will forward outbound packets for that mobile user. The third column is the 
status of the location pointer for the mobile user. There are preferably at 
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least three types of status. They are pending, active, and forwarding. An 
entry for a mobile user is marked as "pending" after an LR receives a 
Universal Registration Request initiated by the mobile user and before it 
receives a positive Reply (authenticated). The LR marks an entry as " active" 
after a positive Universal Registration Reply associated with the mobile user 
has been received. The LR marks an entry as "forwarding" after a validated 
de-registration message with a forwarding address is received before the 
associated Lifetime is expired. 

The fourth column of the LR table is Lifetime. All three types of 
pointer status in the LR table must be associated with Lifetime (time in 
seconds). The Lifetime assigned to an entry with "forwarding" status should 
be reasonably small to prevent a large amount of entries accumulated in the 
LR table. UMTP must implement Lifetime Update to request extending MN's 
Lifetime of the binding information. The Lifetime Update may be sent by 
any LR on the MN's location chain or by its home LR and MN. To support 
Lifetime Update before the Lifetime expires, Lifetime Update Requests 
generated by a MN must be directed on the path leading to the Home 
Network of the mobile user. An LR must not make any decision based on 
expired information. The fifth column is the style of replay protection in use. 
If a received Universal Registration Request contains a replay protection 
extension requiring a style of replay protection not supported by the LR, the 
LR must reject the Universal Registration Request and send a Universal 
Registration Reply with the value in the Code field set to 
UNSUPPORTED_REPLAY_PROTECHON. 

Since the MN may perform Universal Registrations in parallel with 
regular registrations at its home network, the MN must keep one replay 
protection mechanism and sequence for the LR and a separate mechanism 
and sequence for the HA. When using nonces for replay protection, the 
identification field in the Universal Registration Request/Reply messages is 
used. The sender of the message is required to set the high-order 32 bits of 
the identification field to the value of the nonces that will be used by the LR 
in the next Universal Registration Request/Reply message sent to this LR 
node. The low-order 32 bits of the identification field are required to be set to 
the value of the nonces being used for this message. 
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Thus, in each message, the LR communicates to the target LR the 
value of the nonces that will be used the next time. If no messages are lost in 
the network, the LR and the target LR can remain synchronized with respect 
to the nonces being used. If, however, the target LR receives a message with 
what it believes to be an incorrect nonce, it may resynchronize with the LR 
by using a Universal Registration Request. 

For example, as shown in FIG. 4, if the current location of MN is LR 
2122 there may be a location chain setup from LR1121 (Home network) to 
LR112, then to LRU, LR1, LR2, LR21, LR212 and finally to LR2122. 

A Layer i LR must maintain location information for at least the 
following three types of mobile users. (1) Visitor: a mobile user who is 
registered (i.e. subscribes service) outside the coverage area of the LR and is 
roaming within the coverage area of the questioned LR. (2) Native Local 
Roamer: a mobile user who is registered within the coverage area of the LR 
but is currently located within a different Layer i-1 coverage area than that 
where it is registered. (3) Native Traveler: a mobile user that is registered 
inside the coverage area and roaming outside the coverage area of the 
questioned Layer i LR. For example as shown in FIG. 4, suppose a mobile 
user subscribes its service with LR1121. It is a Visitor for LR2122, LR212, 
LR21 and LR2 if it registers with LR2122. It is a Native local roamer for LRU 
if it registers with LR1111. It is a Native Traveler for LR1121, LR112, LRU 
and LR1 if it registers with any LR with a root other than LR1. As long as a 
mobile user stays within its Layer i-1 home coverage area, there is no 
location information needed in the Layer i LR for that mobile user. 
Considering the localized mobility behavior of the mobile users, the memory 
size, searching delay, and accordingly the complexity and cost of the LR is 
thus greatly reduced. 

To support heterogeneous RAN technologies in the proposed 
solution, Agent Advertisement must be able to be implemented on multiple 
layers of the hierarchical structure. For example, a cellular routing area may 
be associated with a Layer 1 network entity and a satellite cell may be 
associated with a Layer 2 LR, etc. The Layer i (e.g. i = 1) network entity must 
announce its presence via an Agent Advertisement message for application / 
(e.g. cellular) mobile users where the lowest coverage area of application / is 
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associated with the Layer i coverage area. Preferably, there is an "RT" flag in 
the Agent Advertisement message to distinguish whether the Regional 
Tunnel management is supported by the local system. The flag is inserted in 
one of the reserved fields, if IP protocol is used over the air. 

5 

Another Flag is "IR" indicating whether Intelligent Routing is 
supported. The Global Challenge must be included regularly in the Agent 
Advertisement message for security considerations if it is implemented by 
the system. The Layer i LR IP address (care-of address) and its NAI is 
10 advertised in the Agent Advertisement message. If IP is used over the air, 
the LR NAI extension must appear in the Agent Advertisement message 
after predetermined advertisement extensions. 

There may be multiple care-of addresses and NAIs in the Agent 
15 Advertisement message. The first care-of address and NAI must be those for 
the Layer i LR. The bottom layer LR must continue to send Agent 
Advertisements, so that any mobile nodes already registered with it will 
know that they have not moved out of range of the region and that the 
network entity has not failed. A network entity may indicate that it is "too 
20 busy" to allow new mobile nodes to register with it, by setting the "B 1 bit in its 
Agent Advertisements. An Agent Advertisement message must not have the 
'B' bit set if the T bit is not also set, and at least one of the *F' bit and the 'H T 
bit must be set in any Agent Advertisement message sent. 

25 The advertising network entity must include its NAI in the Agent 

Advertisement Message to support UMIP. If present, the network entity 
NAI extension must appear in the Agent Advertisement message after 
predetermined advertisement extensions. By comparing the domain part of 
the network entity's NAI with the domain part of its own NAI, the mobile 

30 node can determine whether it is in its home domain or in a visited domain, 
and whether it has changed domain since it last registered. 

As soon as a valid Universal Registration message is received at a 
Layer i LR at the bottom and above layer of the associated application, 
35 additional extensions may be added to the message. They are, not inclusive, 
NEW ADDRESS (NAI) is added at the bottom layer of the application. 
Hierarchical LR extensions (Layer i (above the bottom layer of the 
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application) LR NAI and its IP address) may also be appended in the 
message for intelligent routing considerations. 

The initial stored Layer i LR NAI (serves as Current ID) of an MN 
5 when its power is on must be its own MN NAI. The MN may register a care- 
of address or any other local index adopted by the associated RAN with the 
LR. It is noted that the newly discovered Layer i LR may be its own Home 
LR (HA). 

10 Multiple addresses can be assigned to a mobile user, each for a 

different application. Extensions are defined to carry the active application 
addresses in the combined Universal Registration Request message. 
Receiving a Multiple address extension from a Universal Registration 
Request, the LR should store that information as part of the mobile user 

15 profile associated with the mobile node. The information should be 
accessible from the LR table of the LR. 

The RAN can implement any MN movement detection mechanism 
adopted by the RAN system. One preferred MN movement detection 

20 mechanism is described as follows. In UMCP, the MN needs no knowledge 
of the core network architecture and therefore, there is no need for this type 
of information to be transmitted regularly over the band limited wireless 
channels. All an MN is concerned about, from the registration perspective, is 
to monitor the NAI of the bottom layer LR's common control channel 

25 associated with an application. The movement detection uses the NAI of the 
LR that is sent on the common/ dedicated control channels or in the Agent 
Advertisement messages if IP is used over the air. The MN should lock to 
the identified LR, (the details of the LR identification process being outside 
of the scope of the present invention), and keep track of LR NAI extensions 

30 from all the Advertisements received. If the received NAI should change, 
the mobile node must assume that it has moved. For example. Suppose the 
MN of application J for a mobile user receives an Agent Advertisement from 
a Layer i (the lowest layer for application J) LR and discovers that it is in a 
new Layer i LR coverage area (paging area, routing area, and zone, etc.). The 

35 MN must initiate the registration process by sending a Universal 
Registration Request to the newly discovered Layer i LR if the Agent 
Advertisement indicates that it supports Universal Registration. To support 
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user authentication with Global Challenge, a reply to the Global Challenge 
must be included as part of the Universal Registration Request message. 

Upon receipt of a validated Universal Registration Request, an LR 
5 must register the IP address of the network entity from which the Universal 
Registration Request was sent. Associated information must also be stored 
and indexed by the mobile user's NAL This includes the mobile user's NAI, 
Status and Lifetime. The status is marked "pending." If the LR does not have 
die authentication information, it will relay the Universal Registration 
10 Request to the next LR on the path toward the MN's home network, and may 
eventually reach the home LR, for authentication. The LR will authenticate 
the request if it contains all the security information. After successful 
authentication, the Status will be marked "active". A Registration Reply 
message may also be generated and sent along the location chain toward the 
15 mobile node. The Registration Reply message may also include other 
information such as user profile (to support VHE) and security information 
(to support mobile user authentication), and billing information. 

Upon receipt of a Registration Reply message, the LR needs to 
20 validate the message and check if there is already an entry "pending". If the 
Reply indicates that the registration request is accepted, the Status of the 
mobile user entry will be marked "active". The LR may then forward the 
Reply message to the next LR along the path toward the MN. 

25 On the Registration update path, each LR, other than the bottom layer 

LR, may add a Hierarchical LR extension to the Registration message. This 
information may be used for the downstream LRs (according to the location 
update chain) to update their LR tables. It could also be used for further 
route optimization. One or more Hierarchical LR Extensions may be present 

30 in a Universal Registration Request in the Core Network. When these 
extensions are added to a registration request by an LR, the receiving LR sets 
up a pending registration record for the mobile user, using the IP address of 
the LR from which the Universal Registration Request is received as the 
location pointer for the mobile user. Furthermore, a new extension is created 

35 and the extension must be appended at the end of all the extensions that had 
been included by its upstream LRs as part of its registration message. If 
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multiple Hierarchical LR Extension is not implemented, a receiving LR will 
replace the Hierarchical LR extension with one carrying its own information. 

The Hierarchical LR Extension should only be added on its upward 

5 update path (from layer i to layer i+1). The extension of a higher layer 
should be appended after that of a lower layer if multiple Hierarchical LR 
Extension is implemented. The Hierarchical LR Extension may be defined as 
that specified in Mobile IP Regional Tunnel Management by E. Gustafsson, A. 
Jonsson, and C. Perkins, with following modifications. Collectively, the LR 

10 network must be able to set up a location chain for any of the mobile users 
that are outside their registered networks (HA). The location chain must 
begin at the bottom layer Home LR and end at the current location of the 
mobile user. All the pointers of the location chain are routable IP addresses. 
Each link of the location chain may point to its next higher layer, a next 

15 lower layer LR (or another network entity) of the same domain (sub-tree) or 
point to a root LR of a different domain if the LR is a root LR itself. A pointer 
may also point to any other LR (or network entity) for efficiency 
considerations. A timer is set whenever a Universal Registration Request 
message is sent. A retry or a Registration Failure (after N>=0 failed retries) 

20 message is sent to the appropriate party only when the timer expires. 

It is highly desirable to have a fully distributed location update 
process in such a system dealing with global mobility management and real 
time applications. As soon as a Location Register receives a Universal 
25 Registration Request it will make a decision on whether it is the last hop of 
the journey. If it is not, it will decide the next hop for the Universal 
Registration message. All mobility management message routing decisions 
should be made based on, in the preferred embodiment, the identities (NAI) 
of the mobile user, previous LR and current LR.. 

30 

There should be no direct involvement of a mobile node in the de- 
registration process. The de-registration process should be part of the 
location update process that is mobile user initiated and is carried out by the 
collective efforts of the LR network. 

35 

All the LRs that were on the location chain associated with the MN's 
current location of a mobile user and are no longer on the location chain 
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associated with the mobile node's new location should be informed by a De- 
registration message and the database be updated accordingly. 

After validating the received De-registration message, any LR may 
update its associated data entry indicating the new location (IP address) of 
the mobile user with a status "forwarding". The forwarding pointer may 
help, for instance, to forward the upcoming packets of the roaming mobile 
user to its new location. The forwarding pointer is valid before its Lifetime 
expires. After Lifetime has expired, the associated entry will be removed 
from the LR's database. At this point, all the information of the mobile user 
such as the user secret data, user profile, etc. should also be removed from 
the LR's database. 

For example, suppose that a mobile subscriber has been assigned to 
LR1121 as its registered Home address (NAI), as shown in FIG. 4. If the 
mobile node remains within the coverage of LR 1121, there will be no 
location information in the LR hierarchy since by default the mobile user is 
assumed at home if there is no location information available at any LR. 
Next, suppose that a mobile node attempts to register within the coverage 
area of LR2122. A location chain will be set up beginning from its home LR 
and ending at LR2122. There are several potential ways to set up the location 
chain. One possible way is as follows. A pointer contains the IP address of 
next upper layer LR in each of the LRs (except the top layer) in the mobile 
user's Home domain. For example, a pointer exists in LR1121 pointing to 
LR112, etc. At the top layer LR of the mobile user's home domain there is a 
pointer pointing to the root node of the visiting domain (LR 2). In each of the 
LRs of the mobile user's Foreign domain, a location pointer exists pointing to 
the next lower layer LR where the mobile user is located. For example, a 
pointer at LR 2 indicates that LR 21 is the next hop of the associated location 
chain. The LR 21 has a pointer pointing to LR 212. The LR 212 has a pointer 
pointing to LR 2122 and the latter has a link layer connection (e.g. on 
common control channel) to the MN. 

Another approach is to bypass some layers of the LRs. For example, 
the pointers of the associated LR's in the MN home domain can be the root 
node LR 2 of the Foreign domain to reduce the hop count. 
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When an MN moves to a different location area after it has registered 
successfully, for example, it has registered with LR 2122 and now moves to 
the coverage area of LR 2121, the registration message doesn't have to go all 
the way back to LR 1121. Practically, it may be half a world away. The only 
change needed is to update the associated pointer in LR 212, LR 2122 and 
setup a new pointer in LR 2121. All these updates are performed locally. 

Since the location information is locally available in the LRs of both 
the Home and Foreign domain of a mobile user and statistically, most of the 
traffic (both inbound and outbound) is generated in these domains, the time 
delay and the associated time jitter is thus greatly reduced. For example, a 
call to an MN, with Home LR 1121 and currently registered at LR 2122, is 
generated in the coverage area of LR 2121, which will find the called party's 
location by accessing LR 2121, LR 212 and LR 2122 locally. 

It is possible that the communication system may be owned by 
multiple entities. Therefore, there are possibly two categories of neighboring 
LRs. The first type of LRs are those that share the same operational 
authority. In this case, they may share the same secret data. The second type 
of LRs are those that are under a different operational authority. There must 
be a way of security key management to support setting up security 
association among these LRs. 

It is assumed that security associations have been set up and are able 
to work properly between domains (collection) of LRs from different 
operators. It is also assumed that the security associations have already been 
set up between the LRs. It is further assumed that the LRs from different 
domains must be compatible, that is, they must support at least one common 
type of encapsulation, compression mechanisms, etc. It should be noted that 
the security association is set up on an operator to operator basis rather than 
on a call to call basis. 

An MN-HA Authentication extension must be included as part of a 
Universal Registration Request when an MN performs a Universal 
Registration. Receiving a Universal Registration Request, an LR will confirm 
the validity of the MN if there is a local copy of MN associated security data. 
It will update its location database accordingly and acknowledge the location 
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update to its upstream (according to the location update chain) network 
entity if the mobile user is locally authenticated. Otherwise, it will reject the 
request (by ignoring the request or sending a NACK) if there is a local copy 
of the MN associated security data and the authentication fails. If there is no 
such security data locally available, the LR will relay the registration 
message to the next hop along the path to the mobile user's Home network 
asking for authentication. In the mean time, the newly updated location 
pointer will be marked as in a "pending" stage with a limited Lifetime until a 
positive reply is received from the downstream (according to the location 
update chain) LR. If the associated Lifetime expires or a negative reply is 
received for the pending information for the mobile user, the request is 
rejected and the associated data discarded. If a positive reply is received 
before the associated Lifetime expires, the associated location information 
will be upgraded from "pending" to "active" state and an acknowledgement 
message is sent to its upstream (according to the location update chain) 
network entity. 

The authentication among LRs is implemented with the help of 
Authentication extensions. It shares the same format and default algorithm 
support requirements as the three authentication extensions defined for base 
Mobile IP, but is distinguished by its type. The authenticator value is 
computed from the stream of bytes including the shared secret, the UDP 
payload (that is, the Universal Registration Request or Reply message), all 
prior extensions in their entirety, and the type and length of this extension, 
but not including the authenticator field itself nor the UDP header. This 
extension is required to be used in any Universal Registration Request and 
Reply messages. 

The LR that processes the location update successfully generates a 
Universal Registration Reply only in two conditions. The first condition is 
when the LR is the ending point of a forward location update process. One 
such example is when it is the bottom layer LR in the Home domain of the 
mobile user. Another example is when it is the LR that is knowledgeable of 
the security data of the mobile user and there is no need to further propagate 
the location update message in the system. 
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The second condition to generate a Universal Registration Reply is 
when an LR receives a Universal Registration Reply for a pending mobile 
user from its downstream LR The Universal Registration Reply will be 
relayed to the upstream (according to the location update chain) network 

5 entity. Generating a Universal Registration Reply message, a downstream 
(according to the mobile user's location updating chain) LR must direct the 
message to the next upstream LR IP address that is available from the 
Hierarchical LR extension or the New Address extension of the previously 
received Universal Registration Request message recorded as a pending 

10 pointer in the LR table. The LR that initiates Universal Registration Reply 
distributes appropriate security data (e.g. registration key or Challenge- 
Reply vectors) to the associated LRs. For instance, the LR may use a Mobile 
User Key Reply extension added to the Universal Registration Reply 
message, or it may use other AAA functions. User profile extension may 

15 also be included as part of the Universal Registration Reply message. 
Distribution of security data and user profile information makes it locally 
available to the visited network which in turn reduces the time delay and the 
associated time jitter incurred by triangle routing (tromboning) in the 
process of authentication and service provisioning. 

20 

If the Mobile-Foreign LR Authentication extension is present in a 
Universal Registration Request message, the LR in the foreign domain will 
perform the authentication. Similarly, if a Foreign-Home Authentication 
extension is present in a Universal Registration Request message, the 
25 authentication is performed between the LRs of the visited and home 
domains. 

If everything works fine, all the network entities that sent out a 
Universal Registration Request message must receive one and only one 

30 Universal Registration Reply. When an LR generates or receives a Universal 
Registration Reply, it performs a memory look up function to determine 
where to relay this message. The bottom layer LR in the visited network 
must send a Universal Registration Reply to the associated MN when a 
successful Universal Registration Reply is received from its downstream 

35 (according to the associated location chain) LR. 
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It should be noted that the Universal Registration Request/Reply 
messages may need to be re-coded on some of the legs on the location update 
chain due to encryption and security considerations. If, for instance, the 
Mobile User Key Reply extension is present, the LR that receives the 

5 Universal Registration Reply decrypts the security data. It may (when 
necessary) then add, for instance, a new Mobile User Key Reply extension to 
the Universal Registration Reply message, before relaying it to the next LR. 
The new Mobile User Key Reply extension contains the security data, 
encrypted with a secret shared between the LR and the next hop LR in the 

10 hierarchy. 

This Universal Registration Reply relaying process is repeated in 
every participating LR in the hierarchy, until the message reaches the bottom 
layer LR where the mobile user is located. When the bottom layer LR 
15 receives the Universal Registration Reply, it perforins a memory look up 
function, and relays the reply to the mobile node. 

Existing IP encryption technologies are proposed to carry the security 
data. The existing IP authentication technologies (AAA and security 

20 extensions) are proposed to support the LR authentication processes. The 
security extensions are part of Universal Registration Request and Universal 
Registration Reply messages. For example, when an LR receives a Universal 
Registration Request from another LR, it is required to verify the 
authentication extension in the message, using the mobility security 

25 association it shares with the sending LR. The authentication extension is 
required for Universal Registration messages. If the authentication succeeds, 
then the location database is updated accordingly. Otherwise, an 
authentication exception should be raised. 

30 Each mobile user location update triggered by a Universal 

Registration Request is associated with a maximum Lifetime. When sending 
the Universal Registration Request message, the associated LRs should set 
this Lifetime to the remaining registration Lifetime. Each following location 
update for the same mobile user should refresh the Lifetime. Since there is 

35 an effective de-registration process, the Lifetime parameter should be set to a 
reasonably large value for network bandwidth efficiency considerations. 
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Billing functionality is usually partitioned between usage creation (tier 
1), usage aggregation (tier 2), and invoicing (tier 3). In UMIP, usage creation 
and aggregation are combined. The combined function is distributed in the 
LR's in layer i (i=l for the RAN, corresponding to LI in Fig. 1, or i=2 in the 
CN, corresponding to L2 in Fig. 1). The network operator can decide 
whether this combined billing functionality is in the RAN or the CN. 

In addition to basic subscriber and services information, each LR on 
the location chain of layer i will contain subscriber billing information that is 
usually kept in a billing invoicing system (tier 3). For example, the LR will 
contain information about allowed time of day access, different levels of 
service to be provided, and credit/prepaid status. 

Since the bearer paths flow through the LR's, the LR records the traffic 
generated associated with a subscriber. Subscriber traffic information, in 
addition to the subscriber billing information kept in the LR, will allow the 
LR to create the CDRs (Call Detail Records) and forward these to the billing 
invoicing system that generates the user invoices. The billing invoicing 
system contains information that is needed to generate the invoice, e.g., 
name, address, credit card number, billing address and phone number. 

When a subscriber is in a visited network, the visited billing invoicing 
system will collect the subscriber's CDRs and forward these to the 
subscriber's home billing invoicing system. 

This distributed billing scheme does not require centr aliz ed billing 
mediation devices that collect usage information from all network elements, 
since usage will be determined at the source LR (e.g., LR1121 or LR 112 in 
Fig. 1). In addition, a network operator will not have to deploy separate 
'prepaid servers' since the prepayment status information is also available at 
the source LR. Fewer communication resources will be spent on sending 
subscriber usage data in the network, and the result will be that more 
bandwidth is available for user traffic. 

The subscriber billing information in a visited LR is distributed to the 
LR together with the Registration Reply message. Conversely, if subscriber 
billing data is updated in the home network's LR (e.g., a change in the levels 
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of service provided), it will be forwarded to the current LR where the 
subscriber is registered. 

The subscriber can access his billing information stored in the local LR 
where he is currently registered. The information available includes levels of 
service allowed, and prepaid status. This local access allows the subscriber 
to check in real-time his billing status. 

The flowchart of FIG. 5 shows the response of an LR of layer i > 1 in 
the communication system operating in accordance with an embodiment of 
the present invention when receiving a registration request. After receiving 
a registration request, step 20, an LR authentication determination is made, 
step 22. In case the LR is not authenticated, a message with the 
authentication failure is sent to the sending Location Register, step 24, and 
the process stops. In case the LR is authenticated, then a determination is 
made at step 26 whether the layer i processing node is on the home branch, 
with z=2. If yes, then a reply is generated, step 28, and flow proceeds to FIG. 
6. Otherwise, flow proceeds to step 30, where a determination is made 
whether an entry exists. If yes, a reply is generated at step 28, and flow 
proceeds to FIG. 6. If not, then flow proceeds to step 32 where a 
determination is made whether the node processing the message is a foreign 
root node. If yes, then a determination is made at step 34 whether the mobile 
node is from another foreign domain. If yes, then at step 36, de-registration 
is sent, the forward link address carried in the message is set equal to LRn(2) 
and the target address for the message to be sent is set equal to the current 
root node. 

Thereafter at step 38, to send the registration request to the home root 
node with the forward link address equal to the node processing the message 
address, the target address is set equal to the home root node. Thereafter at 
step 40, an entry with a pending status is created. If the mobile node is not 
from another foreign domain at step 34, then at step 38, to send the 
registration request to the home root node with the forward link address 
equal to the node processing the message address, the target address is set 
equal to the home root node. If the node processing the message is not the 
foreign root node at step 32, then flow proceeds to step 42, where a 
determination is made whether the node processing the message is on the 
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home branch. If yes, then to send the registration request home, the target 
address is set equal to the address of LR(z-l) at step 46, and an entry with a 
pending status is created at step 40. If the node processing the message is 
not on the home branch at step 42, then to send the registration request to the 
5 parent LR, the target address is set equal to the address of LR(z+l) at step 44, 
and an entry with a pending status is created at step 40. 

Thereafter, a determination is made whether the registration request 
with the forward link address has been received at step 48. If yes, then the 

10 pointer indicating the next Location Register in the chain toward the mobile 
node is set equal to the forwarding link address at step 54, the registration 
request with the forwarding link address is sent at step 56, and the process 
stops. If the registration request is received without the forwarding link 
address at step 48, then the pointer indicating the next Location Register in 

15 the chain toward the mobile node is set equal to the IP address of the 
sending Location Register at step 50, the registration request is sent without 
the forwarding link address at step 52, and the process stops. 

The flowchart of FIGs. 6 and 7 show the response of an LR in the 

20 communication system operating in accordance with an embodiment of the 
present invention when generating a registration reply. After a generation 
reply decision is made, step 28, a determination is made whether the mobile 
node is authenticated at step 72. If not, then a reply with the authentication 
failure is sent to the sending Location Register at step 74, and the process 

25 stops. If the mobile node is authenticated at step 72, then the user profile is 
extracted at step 76. Thereafter, a determination is made whether the mobile 
node was at home network at step 78. If yes, then at step 80, an entry is 
created setting the pointer indicating the next Location Register in the chain 
equal to the forwarding link address carried in the registration request 

30 message, or the sending Location Register address, depending on the status 
of the pointer. Then, the target address message is set equal to the sending 
Location Register. Thereafter, flow proceeds to block A, step 81 of FIG. 7. If 
the mobile node was not at home at step 78, then a determination is made 
whether the mobile node is now at home at step 82. If yes, then a 

35 determination is made whether to send de-registration up at step 84. If yes, 
then at step 86 de-registration is sent with the forwarding link address equal 
to LRn(2), the target address is set equal to the address of LR(i+l), and 
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Lifetime is set. Thereafter, Lifetime is set for RR and a reply is sent home at 
step 88, the entry is removed at step 90, and the process stops. 

If there is no need to send up the de-registration at step 84, then at 
step 92, the de-registration is sent with the target address set equal to the 
address of the layer 1 Location Register on the home branch. Thereafter, 
Lifetime is set and a reply is sent home at step 88, the entry is removed at 
step 90, and the process stops. 

If the mobile node is not now at home at step 82, then at step 94, a 
determination is made whether the node processing the message is in a 
foreign domain. If yes, then a determination is made at step 96 whether to 
send de-registration. If yes, then at step 98, de-registration is sent with the 
target address set equal to the current pointer indicating the next Location 
Register in the chain, the forwarding link address is set equal to LRn(2), and 
Lifetime. Thereafter at step 100, the entry is updated by setting the pointer 
equal to the address of the sending Location Register and by setting the 
target address equal to the pointer. Thereafter, flow proceeds to block B, 
step 101 of FIG. 7. If the de-registration is not sent at step 96, then flow 
proceeds to step 100 as discussed above. If the node processing the message 
is not in the foreign domain at step 94, then a determination is made whether 
the node processing the message is on the home branch at step 102. If not, 
the flow proceeds to step 96 as discussed above. If yes, then a determination 
is made whether the mobile node roams across the root node at step 104. If 
the mobile node does not roam across the root node at step 104, then a 
determination is made whether to send de-registration at step 106. If de- 
registration is to be sent, then flow proceeds to step 98 as discussed above. If 
not, then flow proceeds to step 100 as discussed above. If the mobile node 
does roam across the root node at step 104, then a determination is made 
whether the mobile node is now in a foreign domain at step 108. If yes, then 
flow proceeds to block C, step 109 of FIG. 7. If the mobile node roams to a 
foreign domain at step 108, then at step 110, de-registration is sent, and if i=I, 
the target address is set equal to the current pointer, else the target address is 
set equal to the address of a parent LR £+1. In addition, the forwarding link 
address is set equal to LRn(2), and Lifetime. Thereafter, at step 112, if i is 
greater than 2, a binding update is sent home with the forwarding link 
address set equal to the node processing the message, with the target address 
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set equal to the address of LR(i-l) on the home branch, and with Lifetime. 
Thereafter, flow proceeds to step 100 as discussed above. 

If the determination at step 108 was yes, then a determination is made 
s whether the mobile node roams from a foreign domain at step 120. If yes, 
then at step 122, a de-registration message is sent with the target address set 
equal to the current pointer, the forwarding link address set equal to layer 2 
Location Register on the new branch (i.e., LRn(2)), and with Lifetime. If the 
mobile node was not in the foreign domain at step 120, then a determination 
10 is made whether to send de-registration and a binding update at step 124. If 
yes, then at step 126, de-registration is sent with the target address set equal 
to the current pointer, with the forwarding link address is set equal to layer 2 
Location Register on the new branch (i.e., LRn(2)), and with Lifetime. If the 
determination at step 124 was not to send de-registration and a binding 
15 update, then at step 130, the entry is. updated to the pending status and the 
pointer is set equal to the forward link address carried in the registration 
request message. 

After de-registration is sent, flow proceeds to step 128 where a 

20 binding update is sent home with the forwarding link address set equal to 
the forwarding link address carried in the registration request message, with 
the target address set equal to the address of LR(i-l) on the home branch, 
and with Lifetime. Thereafter, at step 130, the entry is updated to the 
pending status and the pointer is set pending by setting pointer equal to the 

25 forward link carried in the registration request message. At step 132, a 
determination is made whether to send the reply along the home branch. If 
yes, then the target address is set equal to the address of parent LR(z+l) at 
step 134. If not, then the target address is set equal to the pointer indicating 
the next Location Register in the chain at step 136. Thereafter, flow proceeds 

30 to block B, step 101, and then to step 140, where Lifetime is set, a reply is 
sent, and status is set equal to active. Thereafter, the process stops. If flow 
proceeds from block A, step 81, then at step 138, a binding update message is 
sent with the target address set equal to layer 1 Location Register on the 
home branch (Le., LRh(l)), and with the forwarding link address set equal to 

35 the node processing the message. Thereafter, flow proceeds to step 140 
where Lifetime is set, a reply is sent, and status of entry is set equal to active. 
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The flowchart of FIG. 8 shows the response of an LR of layer i > 1 of 
the communication system operating in accordance with an embodiment of 
the present invention when receiving a registration reply. After a layer i 
Location Register, i being greater than 1, receives a registration reply, step 
150, an LR authentication determination is made at step 152. If not 
authenticated, then at step 154, a message with authentication failure is sent 
to the Location Register that sent the reply, and the process stops. 

If authenticated at step 152, then a determination is made whether the 
node processing the message is on the home branch at step 156. If not, then 
the target address is set equal to the pointer at 158. If the node processing 
the message is on the home branch at step 156, then a determination is made 
whether to send along the home branch at step 162. If not, then flow 
proceeds to step 158 as described above, where the target address is set equal 
to the pointer. If the determination at step 162 is to send along the home 
branch, then the target address is set equal to the address of parent LR(h-I) at 
step 164. After the target address is set, a positive determination is made at 
step 160. If the reply at step 160 is positive, then at step 166, status is set 
equal to active and Lifetime is updated. Thereafter, a reply is sent at step 
168, and the process stops. If the reply at step 160 is not positive, then the 
entry in the LR table is deleted at step 170, and a determination is made 
whether to send a negative reply at step 172. If not, the process stops. If a 
negative reply is to be sent, then the reply is sent at step 168, and the process 
stops. 

The flowchart of FIG. 9 shows the response of a mobile node in the 
communication system operating in accordance with an embodiment of the 
present invention when generating a registration request. After the mobile 
node receives a paging or mobile IP agent advertisement message at step 
180, the new network access identifier is set equal to the received network 
access identifier at step 182. Thereafter, at step 184, a determination is made 
whether the new network access identifier equals the current network access 
identifier. If yes, then the process stops. If not, then the registration request 
is sent to Location Register (1) at step 186, and the process stops. 

The flowchart of FIG. 10 shows the response of a mobile node in the 
communication system operating in accordance with an embodiment of the 
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present invention when receiving a registration reply. After the mobile node 
receives a reply at step 190, an authentication determination is made at step 
192. If the authentication determination is no, the process stops. If the 
authentication determination is yes, then a positive determination is made at 
5 step 194. If the reply is positive, then at step 196, the address is updated, the 
current network access identifier is set equal to the new network access 
identifier, and registration complete is indicated. Thereafter, the process 
stops. If the reply is not positive at step 194, then a re-send determination is 
made at step 198. If the re-send determination is no, then the process stops. 
10 If the re-send determination at step 198 is yes, then at step 200, a registration 
request message is re-transmitted, and the process stops. 

The flowchart of FIG. 11 shows the response of a mobile node in the 
communication system operating in accordance with an embodiment of the 

15 present invention when generating a Lifetime update request. After 
generating a Lifetime update request at step 210, a determination is made at 
step 212 whether Lifetime is about to expire. If not, then the process stops. If 
Lifetime is about to expire at step 212, then at step 214, a Lifetime update 
request is sent to Location Register (1), to which the mobile node is locking, 

20 and thereafter the process stops. 

The flowchart of FIG. 12 shows the response of a mobile node in the 
communication system operating in accordance with an embodiment of the 
present invention when receiving a Lifetime update reply. After the mobile 
25 node receives a Lifetime update reply at step 220, an authentication 
determination is made at step 222. If the authentication determination is no, 
the process stops. If the authentication determination is yes at step 222, then 
at step 224, Lifetime is updated, and the process stops. 

30 The flowchart of FIG. 13 shows the response of an LR with a layer = 1 

in the communication system operating in accordance with an embodiment 
of the present invention when receiving a registration request. After 
Location Register (1) receives a registration request at step 230, a pending 
entry is created at step 232 with the pointer set equal to the address of parent 

35 LR(z+l). Thereafter, the registration request is relayed to Location Register 
(2) at step 234, and the process stops. 
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The flowchart of FIG. 14 shows the response of an LR with a layer = 1 
in the communication system operating in accordance with an embodiment 
of the present invention when receiving a registration reply. After Location 
Register (1) receives a registration reply at step 240, an authentication 

5 determination is made at step 242. If the authentication determination is no, 
the process stops. If the authentication determination is yes, then a positive 
determination is made at step 244. If the reply is positive, then at step 246, 
the entry is updated by setting status equal to active, and thereafter at step 
248, the reply is relayed to the mobile node. Thereafter, the process steps. If 

10 the reply is not positive at step 244, then the negative acknowledgement is 
processed at step 250, and a send reply determination is made at step 252. If 
the send reply determination is no, the process stops. If the send reply 
determination at step 252 is yes, then the reply is relayed to the mobile node 
at step 248, and the process stops. 

15 

The flowchart of FIG. 15 shows the response of an LR with a layer = 1 
in the communication system operating in accordance with an embodiment 
of the present invention when receiving a binding update. After Location 
Register (1) receives a binding update at step 260, an authentication 
20 determination is made at step 262. If the authentication determination is no, 
the process stops. If the authentication determination is yes at step 262, then 
the entry is updated with the mobile node away at step 264, and the process 
stops. 

25 The flowchart of FIG. 16 shows the response of an LR with a layer = 1 

in the communication system operating in accordance with an embodiment 
of the present invention when receiving de-registration. After Location 
Register (1) receives de-registration at step 270, an authentication 
determination is made at step 272. If the authentication determination is no, 

30 the process stops. If the authentication determination at step 272 is yes, then 
the entry is updated with the mobile node away at step 274, and the process 
stops. 

The flowchart of FIG. 17 shows the response of an LR with a layer = 1 
35 in the communication system operating in accordance with an embodiment 
of the present invention when receiving a Lifetime update request. After 
Location Register (1) receives a Lifetime update request at step 280, an 
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authentication determination is made at step 282. If the authentication 
determination is no, the process stops. If the authentication determination at 
step 282 is yes, then at step 284, the Lifetime request is relayed to the parent 
LR(I+1), and thereafter, the process stops. 

5 

The flowchart of FIG. 18 shows the response of an LR with a layer = 1 
in the communication system operating in accordance with an embodiment 
of the present invention when receiving a Lifetime update reply. After 
Location Register (1) receives a Lifetime update reply at step 290, an 
10 authentication determination is made at step 292. If the authentication 
determination is no, then the process stops. If the authentication 
determination at step 292 is yes, then at step 294, the entry is updated with 
Lifetime set equal to the received Lifetime, and at step 296 the Lifetime reply 
is relayed to the mobile node. Thereafter, the process stops. 

15 

The flowchart of FIG. 19 shows the response of an LR of layer i > 1 in 
the communication system operating in accordance with an embodiment of 
the present invention when receiving a de-registration message. After a 
layer i Location Register, i greater than 1, receives a de-registration message 

20 at step 300, an authentication determination is made at step 302. If the 
authentication determination is no, then at step 304, a message with the 
authentication failure is sent to the Location Register that sent the de- 
registration. Thereafter, the process stops. If the authentication 
determination at step 302 is yes, then a determination is made whether the 

25 node processing the message is above layer 2 at step 306. If not, then at step 
308, the de-registration is sent with the target address for the message to be 
sent set equal to the address of LR(x-l) indicated by the existing pointer. If 
the node processing the message is above layer 2 at step 306, then a 
determination is made whether the node processing the message is on the 

30 home branch at step 310. If the node processing the message is not on the 
home branch at step 310, then the target address for the message to be sent is 
set equal to the current pointer at step 314. If the node processing the 
message is on the home branch at step 310, then a determination is made 
whether to send along the home branch at step 312. If yes, then the target 

35 address for the message to be sent is set equal to the address of parent 
LR(z+l) at step 316. If the determination to send along the home branch at 
step 312 is no, then the target address is set equal to the current pointer at 
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step 314. After setting the target address, flow proceeds to step 318, where a 
de-registration with carry over forwarding link address and Lifetime from 
the de-registration or the default Lifetime is sent. Thereafter, at step 320, a 
determination is made whether the node processing the message is on the 

5 home branch. If not, at step 324, status is set equal to forwarding, indicating 
the status of the mobile node entry, the pointer indicating the next Location 
Register in the chain is set equal to the forwarding link address carried in the 
messages, and Lifetime is updated. Thereafter, the process stops. If the node 
processing the message is on the home branch on step 320, then the entry is 

10 removed at step 322, and thereafter the process stops. 

The flowchart of FIG. 20 shows the response of an LR of layer i > 1 in 
the communication system operating in accordance with an embodiment of 
the present invention when receiving binding update. After Location 

15 Register (i), i being greater than 1, receives the binding update at step 330, an 
authentication determination is made at step 332. If the authentication 
determination is no, at step 334, a message is sent with authentication failure 
to the Location Register that sent the binding update, and thereafter the 
process stops. If the authentication determination at step 332 is yes, then a 

20 determination is made whether to send the binding update at step 336. If 
yes, then at step 338, the binding update is sent with the target address for 
the message to be sent set equal to the address of LR(z-l) indicated by the 
existing pointer, and the forwarding link address carried in the message and 
Lifetime is carried over from the binding update message. Thereafter, at step 

25 340, the pointer is set equal to the forwarding link address, and Lifetime is 
updated. If the determination to send the binding update at step 336 is no, 
then flow proceeds to step 340 as described above, where the pointer is set 
equal to the forwarding link address, and Lifetime is updated. 

30 The flowchart of FIG. 21 shows the response of an LR of layer i > 1 in 

the communication system operating in accordance with an embodiment of 
the present invention when receiving a Lifetime update request. After 
Location Register (i), i being greater than 1, receives a Lifetime update 
request at step 350, an authentication determination is made at step 352. If 

35 the authentication determination is no, then an authentication failure 
message is sent to the Location Register that sent the Lifetime request at step 
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356, and the process stops. If the authentication determination at step 352 is 
yes, then a mobile node authentication determination is made at step 354. If 
the mobile node is not authenticated, then an authentication failure message 
is sent to the Location Register that sent the Lifetime request. If the mobile 
node is authenticated at step 354, then a determination is made at step 358 
whether the layer i processing node is on the home branch, with i=2. If yes, 
then a determination is made whether to update Lifetime at step 360. If 
Lifetime is to be updated, then a new Lifetime is set at step 362 and a 
determination is made whether to send a Lifetime reply at step 364. If not, 
the process stops. If yes, then the Lifetime reply is sent with the target 
address for the message to be sent set equal to the address of LR(z-l) 
indicated by the existing pointer at step 366. Thereafter, the process stops. If 
the determination to update Lifetime at step 360 is no, the process stops. If 
the determination at step 358 is no, then a determination is made whether the 
node processing the message is a foreign root node at step 368. If yes, then at 
step 370, the target address for the message to be sent is set equal to the 
home root node, and at step 372, the Lifetime update request is sent. If the 
node processing the message is not the foreign root node at step 368, then a 
determination is made whether the node processing the message is on the 
home branch at step 374. If not, in order to send the Lifetime update request 
to the parent, the target address for the message to be sent is set equal to the 
address of parent LR(z'+l) at step 376. If the node processing the message is 
on the home branch at step 374, then to send the Lifetime request home, the 
target address for the message to be sent is set equal to the address of LR(z-l) 
on the home branch at step 378. Thereafter, the Lifetime update request is 
sent at step 372. After sending LTR, flow proceeds to step 360 to update 
Lifetime as described above. 

The foregoing description of a preferred embodiment of the invention 
has been presented for the purpose of illustration and description. It is not 
intended to be exhaustive or to limit the invention to the precise form 
disclosed. Obvious modifications or variations are possible in light of the 
above teachings. The embodiment was chosen and described to provide the 
best illustration of the principles of the invention and its practical 
application, and to enable one of ordinary skill in the art to utilize the 
invention in various embodiments and with various modifications as are 
suited to the particular use contemplated. All such modifications and 
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variations are within the scope of the invention as determined by the 
appended claims when interpreted in accordance with the breadth to which 
they are fairly, legally, and equitably entitled. 
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Claims 

What is claimed is: 



1 1. A method of locating a portable transceiver in a communication 

2 system having: 

3 a multiplicity of ports for transferring communication information 

4 through the communication system between a plurality of 

5 transceivers, the portable transceiver being a member of the plurality 

6 of transceivers , each of the plurality of transceivers being coupled to 

7 one of the multiplicity of ports; 

8 a multiplicity of nodes for transferring information between the 

9 multiplicity of ports, each of the multiplicity of ports coupled to one of 

10 the multiplicity of nodes, each of the multiplicity of nodes having 

11 memory capable of storing data indicative of a port to which the 

12 portable transceiver is coupled; and 

13 a plurality of node trees comprising the multiplicity of ports and the 

14 multiplicity of nodes, each of the plurality of node trees having: 

15 a plurality of the multiplicity of ports; and 

16 a plurality of the multiplicity of nodes structured as a hierarchical 

17 system of nodes; wherein 

18 a root node is structured as a highest node in the hierarchical system 

19 of nodes; 
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20 wherein the plurality of node trees includes: 

21 a home tree associated with the portable transceiver, the portable 

22 transceiver having an address indicative of a home port of the 

23 home tree, and the plurality of node trees further includes: 

24 a second tree having a second port, the method comprising the steps 

25 of: 

26 (a) coupling the second port to the portable transceiver; and 

27 (b) adding a first data entry to a root node of the home tree in response to 

28 step (a) of coupling, the first data entry being associated with the 

29 portable transceiver and indicative of a root node of the second tree. 



30 
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